Dynamic Fire Egress

For finding the nearest exit when your building is on fire.
By: Andrew Mackin (ajm536), David Chen (dc854), Hannah Goldstein (hlg66)

Demonstration Video

Project Objective:

In this project, we simulated the spread of a fire in a building and dynamically changed the direction of exit signs based on information on where the fire was. In this way, we were able to provide egress routes that prevented individuals from walking through fire if possible.

Introduction

In case of an emergency, navigating to the nearest and safest exit can prove to be difficult when you are in an unfamiliar location or you don’t know the location of the nearest exit that avoids the emergency event. The Emergency Egress System provides topological guidance to individuals in a building to navigate to the nearest and safest emergency exit through the use of LED arrows attached to exit signs. Through an expanded emergency exit sign design, the addition of arrows placed to the left and right of the sign, individuals are able to receive real-time guidance for which exit(s) are on the shortest and safest path out, and which exits are not.

Design

Physical Model

Figure 1: The expected layout of the Exit signs is shown (left), with the top showing arrows pointing right and bottom showing arrows pointing left. The produced physical model that was integrated with the physical model is shown on the right.

Each of the exit signs is composed of the total of 24 green LEDs creating two X’s on mini breadboards. Each X is composed of 12 LED’s configured in groups of three such that there is a square in the center of the X made from four LED’s (one from each group of three). From this square, the triplets of LED’s are angled evenly outward with right angles between each string of LEDs. Figure XX above shows the overall layout of the LEDs on the breadboard used to create the Exit signs. Each triplet of LED’s was controlled by a separate GPIO pin connected to the RPi4. Each triplet had to be controlled by a separate GPIO pin to avoid maxing out the current that the GPIO pins could handle. In addition, because some of the signs never changed because they were directly next to a physical exit, the required number of GPIO pins for the model was fewer - summing to a total of 14 pins needed for this design (four for both central, navigational signs, and two for each of the three physical exit signs)

Structuring the Abstract Model

Figure 2: The abstract representation of our demo model of Phillips Hall, Second Floor.

We used a graph with various types of nodes and edges to represent the building. We had 4 types of nodes:

Exits: Nodes that represented an exit out of the building
Signs: Nodes that represented a physical sign that could be lit up
Alarms: Nodes that represented smoke alarms
Deltas: Intermediate nodes that represented whether a physical path could be safely traversed

Some nodes, as can be seen in Figure 2, could be both exit and sign nodes if they had a physical sign and represented an exit. Then, we had the following rules for edges:

A directed edge existed from an Alarm a to a Delta a if and only if fire detected by a caused the physical path represented by d to be unsafe to traverse
A directed edge existed from Sign s to Delta d if and only if s was not an Exit and d was a physically directly connected path that could be traveled from s
A directed edge existed from Delta d to Exit e if and only if e was a physically directly connected path that could be used to travel to e
A directed edge existed from Delta d to Sign s if and only if each other Sign pointing to s could route people to face the front of s and d was a physically directly connected path that could be used to get to s
Each Delta node can only have one incoming edge from a Sign node
Each Delta node can only have on outgoing edge

Although in Figure 2, all non-exit Signs were directly connected to exits when ignoring Delta nodes, our model and algorithm both supported passing multiple non-exit signs on the way to an exit. However, determining the new directions would require some small modifications to our code if this were the case. Lastly, edges from Delta nodes to Exit nodes carry the physical distance from the Sign incoming into a respective Sign node to the respective Exit node. For the most part, this representation went smoothly, although as further elaborated in Designing the Algorithm, encoding path lengths in Delta nodes was problematic when calculating the shortest path.

Setting Up the Database

After quite a bit of research, we opted to use a Neo4j database to store our graph data. Conveniently, we were able to obtain a 30-day free development instance of Neo4j’s AuraDB that we could use to store our data and connect remotely. Then, by installing the neo4j Python package using pip, we were able to interface with the database remotely, allowing us to perform queries inside of our programs. Lastly, we were able to hide our credentials to our database using a .env file that contained the credentials and then load those credentials as environment variables using the os package in Python. It took awhile to figure out how to store our Neo4j database but once we found AuraDB instances it became clear that it was what we wanted. We tested this step by connecting to the database and then executing basic Cypher queries and examining the results in the terminal. It was often evident if things were working correctly because verbose error messages would appear otherwise. The sample code provided by Neo4j’s Python Developer Guide proved to be very useful for writing the Python code for this step.

Designing the Algorithm

If there was one point in development of the non-networking software that presented many issues, it was developing the algorithm. It took quite a while to learn different aspects of the Cypher query language and to get the correct results. For this, the Santa’s Shortest Weighted Path blog post proved to be very helpful in providing a baseline for the syntax. We also ran into issues trying to associate the edge “costs” (or physical path distances) in nodes when running our query, but we got around this by storing costs in edges. Overall, the biggest issue we encountered in this step was ordering the syntax correctly, which merely took a lot of research and practice. Our algorithm for calculating the shortest path was as follows:

MATCH path = (startSign:Sign WHERE startSign.id = $sign_id)-[:CONNECTED_TO*]->(exit:Exit) WHERE NONE
            (x in nodes(path) WHERE x:Fire) RETURN path ORDER BY REDUCE(dist = 0, rela in relationships(path) | dist + rela.cost) ASC LIMIT 1

where $sign_id represents the identifier for a given Sign node. A breakdown of each step is as follows:

MATCH path = (startSign:Sign WHERE startSign.id = $sign_id)-[:CONNECTED_TO*]->(exit:Exit)
- Find all paths from a given Sign to an Exit of any length
WHERE NONE(x in nodes(path) WHERE x:Fire)

Ignore any paths where a (Delta) node has a Fire label associated with it

RETURN path ORDER BY REDUCE(dist = 0, rela in relationships(path) | dist + rela.cost)

Calculate the cost of each edge for a given path in the set of paths created by the query up to this point

ASC LIMIT 1

Sort all the paths in ascending order by cost and take the first one (and then return it)

Then all we needed to do was compare the old direction to the one associated with the Delta node in the path returned by the algorithm to determine if the direction of a sign needed to change. Correctness was evidenced through manual testing of our model and by examining the output of the queries.

Interfacing with the LED Signs

Performing this step of the project proved to be quite simple and we ran into no significant issues. For each Sign, we added fields which contained the GPIO pin numbers for each quadrant in the sign. Then, based on the direction calculated by the algorithm, we sent signals to the LED signs after calculating which quadrants needed to be lit. Correctness was evident by simply trying different directions for each sign.

Networking with Sensors

Figure 3: Networking the Temperature Sensors

To model the system, we wanted to have the temperature sensors alert the Raspberry Pi when there is a fire similar to how it would happen with a smoke detector and central monitoring system in an actual building. We decided to use the Huzzah ESP8266 breakout which functioned as a networking chip which will relay the information from the temperature sensor to the Raspberry Pi. We originally wanted to use HTTP requests, but it was simpler to use MQTT which was common in IoT devices where suscribers subscribe to certain topics to get certain messages. In this case, the Raspberry Pi would subscribe to the information from the individual temperature sensors as different topics.

We originally planned to have one networking chip per sensor, but it would end up being too expensive and would duplicate a lot of the same work on each sensor. One problem we ended up having is we opted to use a cheaper temperature sensor which also meant that there was no way to change the I2C address of the sensor. This meant that for the single I2C channel on the HUZZAH, we had to use a multiplexer, so that it could distinguish between the different sensors as shown in Figure 3. This allows the chip to select which I2C channel to read from the multiplexer and get the temperature reading for the appropriate sensor.

Testing

In developing our project, we ran into a number of issues as the result of using technologies for the first time and using unreliable parts. With a few minor exceptions, we were able to meet all the deadlines we set for ourselves. Oftentimes, the correctness of our sprints was evidenced by trivial manual use, although as we put different parts of our project together, we had to manually test different patterns of inputs more thoroughly.

In addition, the hardware components were somewhat unreliable such as the temperature sensors and the I2C multiplexer. Originally, the I2C multiplexer was not working, and it was unable to relay the switch between the different I2C channels, so we had to use a different one. In addition, the temperature sensors were pretty cheap, so they were somewhat unrealiable in giving readings. There were also many parts that had to be connected with wires and unseen loose connections were contributing to the problems we had with the hardware. Overall, we were able to test the individual components of the system in isolation first. The networking component was tested to see if it could send messages to the Raspberry Pi, the abstract model was checked to see if it was generating the correct path based on given inputs, and the LED signs were tested to see if they were lighting up correctly. Afterwards, we combined all our different parts to see if all the components worked together on our physical model. We were able to see the temperature sensors sending the signal to the Raspberry Pi which then controlled the different LEDs to change direction based on the temperature. We concluded our testing by ensuring that the paths were changing in the correct manner based on the LEDs and temperature readings.

Result

All aspects of the project performed as planned in the end. Along the way, there were some difficulties and abnormal behavior resulting from either hardware or software issues (i.e. dead multiplexer, wires not fully connected/ connected incorrectly, and incorrect entries in the database). However, these were resolved and the goals outlined in the description were eventually met. We were able to successfully create a model of a building and demonstrate how a dynamic egress system would work to change exit sign directions based on temperature sensors being triggered.

Conclusion

Our project was able to model how a dynamic egress system would work. It was able to demonstrate what such a system would look like and how it would work. We didn't really run into any specific issues that showed that it didn't work. The model was not as complex as how a real building is laid out as it only demonstrates the basic components of a system. However, it was able to demonstrate the usefulness of such a system on a small scale model that can be extended into a more detailed one.

Future Work

For future work, trying models to add more complex paths to the exits (multiple intermediary signs, for example) and larger data would be an option. In addition, displaying the path on the piTFT screen for a visual layout would also be an ideal extension for more complex buildings. In addition, interfacing between either the heat sensors or the exit signs wirelessly would also increase the usability and reduce the number of hardware issues that were encountered. Furthermore, incorporating paths from multiple floors and buildings with more complex layouts would allow for the expansion of the project and the development of a design that could be incorporated into any building just using the location of sensors, signs, and exits. With this increased complexity in floors and buildings, investigating how to leverage the carrying capacity of hallways and to reduce congestion for larger buildings is also a future consideration.